AWS Security Hubで[Config.1]の重要度がCriticalに変更され、新たに追加された「コントロール失敗理由」を確認し是正してみた
はじめに
今月、AWS Security Hubのコントロール[Config.1]の重要度がMEDIUMからCRITICALに引き上げられました。
さらに、Config.1の失敗検出結果に新たにステータスコード(Reason code)とステータス理由(Description)が追加されました。
AWS Configやリソース記録が無効になっている場合、不正確なコントロール検出結果を受け取る可能性があります。そのため、是正しましょう。
Config.1 checks whether AWS Config is enabled, uses the service-linked role, and records resources for enabled controls. Security Hub increased the severity of this control from MEDIUM to CRITICAL. Security Hub also added new status codes and status reasons for failed Config.1 findings. These changes reflect the importance of Config.1 to the operation of Security Hub controls. If you have AWS Config or resource recording disabled, you can receive inaccurate control findings.
To receive a PASSED finding for Config.1, turn on resource recording for resources that correspond to enabled Security Hub controls, and disable controls that aren't required in your organization. For instructions on configuring AWS Config for Security Hub, see Enabling and configuring AWS Config for Security Hub. For a list of Security Hub controls and their corresponding resources, see Required AWS Config resources for Security Hub control findings.
https://docs.aws.amazon.com/securityhub/latest/userguide/controls-change-log.html
本記事では、追加された失敗理由を確認し、是正までの手順を解説します。
本コントロールのチェック観点は3つあり、これらをすべて満たすことでコントロールが成功します。
- AWS Config(レコーダー)が有効化されているか
- 有効化されているすべてのSecurity Hubコントロールに対応するすべてのリソースタイプがConfigレコーダーで記録できているか
- AWS Configのサービスリンクロール(AWSServiceRoleForConfig)が設定されているか
便宜上、これらを「チェック観点1」「チェック観点2」「チェック観点3」とします。
今回、新たにステータスコード(Reason code)とステータス理由(Description)が追加された理由は、通常のコントロールとは異なり、本コントロールが3つのチェック観点を持つためだと推測されます。
コントロールが失敗した理由
チェック観点1~3のうちどの観点で失敗したか確認します。
確認方法
Security Hubの検出結果からConfig.1を確認できます。
[JSONを表示]から、アップデート内容である新しくステータスコード(Reason code)とステータス理由(Description)が確認できます。
例えば、以下の場合、チェック観点2とチェック観点3が満たされていないため、失敗しています。
{
"AwsAccountId": "012345678901",
"CompanyName": "AWS",
"Compliance": {
"Status": "FAILED",
"StatusReasons": [
{
"Description": "AWS Config isn't recording all resource types that correspond to enabled Security Hub controls. Turn on recording for the following resources: AWS::DMS::Endpoint, AWS::ECS::TaskDefinition, AWS::AutoScaling::LaunchConfiguration, AWS::ApiGateway::Stage, AWS::ElasticBeanstalk::Environment, AWS::SSM::AssociationCompliance, AWS::RDS::DBClusterSnapshot, AWS::S3::AccessPoint, AWS::EC2::LaunchTemplate, AWS::RDS::DBSnapshot, AWS::ECS::Service, AWS::ApiGatewayV2::Stage, AWS::WAFv2::RuleGroup, AWS::AutoScaling::AutoScalingGroup, AWS::SSM::ManagedInstanceInventory, AWS::EC2::Instance, AWS::WAFRegional::Rule, AWS::Lambda::Function, AWS::WAFv2::WebACL, AWS::CodeBuild::ReportGroup, AWS::AppSync::GraphQLApi, AWS::NetworkFirewall::RuleGroup, AWS::WAFRegional::RuleGroup, AWS::NetworkFirewall::FirewallPolicy, AWS::EC2::ClientVpnEndpoint, AWS::EC2::Volume, AWS::SSM::PatchCompliance, AWS::Backup::RecoveryPoint, AWS::StepFunctions::Activity, AWS::Athena::DataCatalog, AWS::EC2::NetworkInterface, AWS::ECS::TaskSet, AWS::Redshift::ClusterSnapshot, AWS::KafkaConnect::Connector, AWS::SES::ContactList.",
"ReasonCode": "CONFIG_RECORDER_MISSING_REQUIRED_RESOURCE_TYPES"
},
{
"Description": "The AWS Config recorder is using a custom IAM role instead of the AWS Config service-linked role.",
"ReasonCode": "CONFIG_RECORDER_CUSTOM_ROLE"
}
],
チェック観点1~3のステータスコード(Reason code)とステータス理由(Description)は以下のとおりです。
ReasonCode
:DescriptionCONFIG_RECORDER_DISABLED
:AWS Config が有効化されておらず、設定レコーダーが起動していません。CONFIG_RECORDER_MISSING_REQUIRED_RESOURCE_TYPES
:AWS Config が、有効化された Security Hub コントロールに対応するすべてのリソースタイプを記録していません。CONFIG_RECORDER_CUSTOM_ROLE
:AWS Config レコーダーが AWS Config のサービスリンクロールではなくカスタム IAM ロールを使用しており、Config.1 の includeConfigServiceLinkedRoleCheck カスタムパラメータが false に設定されていません。
コンプライアンスステータスが失敗(FAILED
)だけでなくNOT_AVAILABLE
の場合もステータスコードとステータス理由がありますので、詳細はドキュメントをご参照ください。
対処方法
チェック観点ごとに対処方法が異なります。
チェック観点1とチェック観点2の是正方法については、以下のブログに手順がまとめられていますので、ご確認ください。
今回はチェック観点3のAWS Configのサービスリンクロール(AWSServiceRoleForConfig)ではなくカスタムロールを利用したため、失敗したと仮定します。
チェック観点3を是正
まず、カスタムロールではなくAWSServiceRoleForConfig
に変更できるかを検討します。
Security Hubのコントロールだけでなく、AWSドキュメントでもAWSServiceRoleForConfig
の利用が推奨されています。
推奨: サービスにリンクされたロールを使用する
サービスにリンクされたロールを使用することをお勧めします。サービスにリンクされたロールは、 が期待どおりに実行 AWS Config するために必要なすべてのアクセス許可を追加します。
https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/manual-setup.title.html
AWSServiceRoleForConfig
は、AWS Configのサービスリンクロールであり、AWSが自動的に作成するIAMロールです。このロールは、AWSサービスが必要とする権限のみを持ち、ユーザーがIAMポリシーを直接修正することはできません。また、サービスリンクロールは通常、SCP(Service Control Policy)の影響を受けません。
そのため、基本的にはAWSServiceRoleForConfig
に変更できるかを検討しましょう。
もしカスタムロールを利用する必要がある場合は、チェック観点3をオフにする方法があります。以下の記事を参考にしてください。
是正するため、カスタムロールからAWSServiceRoleForConfig
への変更方法は以下のとおりです。
- Configの設定でレコーダーを編集します
- サービスリンクロールに変更し保存します
変更後、一時的にセキュリティグループなどのリソースを作成し、Configダッシュボードで確認できるメトリクス「設定履歴のエクスポートに失敗しました(ConfigHistoryExportFailed)」が0であるかを確認します。
もし1となっている場合は、S3バケットへの保存が失敗しています。S3バケットポリシー等を確認しましょう。
メトリクス「設定履歴のエクスポートに失敗しました(ConfigHistoryExportFailed)」が、0
また、数時間後、S3にレコードが保存されているか確認します。6時間ごとにS3バケットに保存される仕様です。
確認後、翌日、Security Hubの[Config.1]のワークフローステータスがRESOLVED(解決済み)になっているかを確認します。
コントロールの是正対応は以上です。
参考
ConfigHistoryExportFailedメトリクスについて
S3バケットへの保存について